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Using standard domain-theoretic fixed-points, we present an approach for defining recursive func- 
tions that are formulated in monadic style. The method works both in the simple option monad and 
the state-exception monad of Isabelle/HOL's imperative programming extension, which results in a 
convenient definition principle for imperative programs, which were previously hard to define. 

For such monadic functions, the recursion equation can always be derived without precondi- 
tions, even if the function is partial. The construction is easy to automate, and convenient induction 
principles can be derived automatically. 

1 Introduction 

Tool support for non-primitive recursion in interactive theorem provers has made good progress in the 
last years. Although the base logic of most proof assistants has no support for general recursion or 
partial functions, tools exist to reduce such definitions to more basic principles in an automated and 
mostly transparent way [23, 2, 17, 5]. 

This paper discusses a class of definitions which are not yet supported by any existing tool: imper- 
ative computations wrapped up in a state monad. These functions present a challenge, since the actual 
structure of the recursion is not directly visible from the definition itself, but depends on the implicit state 
argument. Before considering imperative programs, we first develop our approach in the simpler option 
monad. The method can then be extended to state monads without much difficulty. 

1.1 Notation 

We work in the setting of Isabelle/HOL [20], which implements a variant of classical higher-order logic 
extended with type classes and overloading. Its syntax mostly conforms to standard mathematical no- 
tation, except for a few idiosyncracies that arise from the generic nature of the Isabelle system, notably 
the two versions of implication ( — > and ==>) and universal quantification (V and /\), corresponding to 
the meta and the object level. The reader can safely treat them as interchangeable for the purpose of this 
paper. Function types are written using =>, and other basic types include bool, not and a list. 

1.2 Function Definitions in Isabelle/HOL 

To explain the problem, we briefly outline the state of the art concerning function definitions in Is- 
abelle/HOL [20]. The definition facilities (commonly called the function package [17, 16]) work as 
follows: 

From the specification of a partial function given by a recursive equation fx = Ff x, the function 
package produces a total function / :: cr =>■ r, together with a domain predicate dom :: cr => bool, which 
models the set of values x where the recursion terminates. For values outside the domain, we can still 
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write the term fx, but its value may be unknown or meaningless. The original recursive specification is 
then derived as a theorem, constrained by the domain condition: 

dom x =>fx = F fx 

This condition can be removed by proving that the function is total, i.e., Vx. dom x. An induction rule is 
also derived, which is guarded by the domain condition as well. 

The use of a predicate to describe terminating inputs is shared by various related approaches [9, 10, 6, 
12]. In our classical simply-typed setting, it has the advantage that the function can be used syntactically 
as if it were total. In particular, one can treat a total function as partial temporarily, until its termination 
proof is finished and the predicate can be discarded. This has proved very useful for nested recursion. 
However, for truly partial functions the domain condition does not go away and has to be dealt with in 
proofs. 

1.3 Imperative Functional Programs in Isabelle/HOL 

Imperative HOL [7] is an extension of Isabelle/HOL which allows modeling and reasoning about pro- 
grams that manipulate a heap. It defines a type heap, which models a store where references can be 
allocated and updated. (The details behind the type heap are omitted and can be safely ignored.) 

new-ref :: heap => a ref x heap 
get-ref :: a ref =>- heap =4> a 
set-ref : : a ref => a heap =4> heap 

Heap-modifying programs are modelled as monadic computations in the so-called heap monad: 

datatype a Heap = Heap {heap => {a + exception) x heap) 

return :: a =^ a Heap 

return x = Heap [Pair {Inl x)) 

»= :: a Heap =>- (a- =^> /? Heap) =4> /? Heap 

f >= g = Heap {Ah. case execfh of {Inl x, h') =^> exec {g x) h' \ {Inr exn, h 1 ) => {Inr exn, h')) 

where exec {Heap f) = f. This is nothing more than a state-exception monad, whose state type is heap. 
The singleton type exception is a simplistic way of modelling irrecoverable failure of the computa- 
tion. The primitive heap operations are straightforwardly lifted to monadic operations with the following 
types: 

Ref .new :: a =^ a ref Heap 

Ref .lookup :: a ref a Heap 

Ref .update :: a ref =4> a unit Heap 

We abbreviate Ref .lookup r by \r and Ref .update r x by r := x. Moreover, we use a do-notation 
similar to Haskell, i.e., do x <— /; g x done abbreviates / »= {Ax. g x). For example, here is a data type 
of heap-allocated linked lists, and a function traverse : : a node a list Heap that traverses a linked list 
and turns it into an ordinary list: 

datatype a node = Empty \ Node a {a node ref) 

traverse Empty = return [] 
traverse {Node x r) =dotl<— \r; 

xs ^— traverse tl; 
return {x # xs) 
done 
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The semantics of a monadic computation t is given by a relation [f], where (/?, //, y) £ [ f ] expresses 
that if the computation is executed on heap h, then no exception occurs and y and h' are the result value 
and the new heap, respectively. 

By a slight extension of Isabelle's code generator [13], the monadic terms can be translated to ML 
(using imperative features) or Haskell (using the ST monad). 

1.4 The Catch: Recursive Monadic Definitions 

But there is a catch! While much of Isabelle's reasoning infrastructure can be used for monadic programs 
as well, the function package cannot cope with functions as simple as traverse above. 

There are several aspects of the problem. First, the function package looks at the arguments of the 
function to construct the domain predicate. However, the termination of the function also depends on the 
heap, which is hidden behind the state monad and not a direct argument of the function. 

While this could be solved by breaking the monad abstraction and making the heap a normal argu- 
ment to the function (which would result in very messy code), the second problem is that traverse is 
inherently partial, as the pointer structure on the heap may be cyclic. Thus, the function package could 
only produce conditional equations, and one would lose the possibility to use the code generator, which 
only works for unconditional equations. This limitation of code generation also applies to other partial 
functions, but in Imperative HOL, where partiality is ubiquitous, it is especially problematic. 

The paper on Imperative HOL [7] already observes these shortcomings and provides a workaround 
using a recursion combinator MREC that can express a common case of definitions, including traverse. 
However, the lack of tool support soon becomes a show-stopper as soon as more complex function 
definitions are needed. 

For example, in ongoing work, Bulwahn is formalizing an imperative version of unification. Some 
of his functions do not fall under the scheme of MREC, and had to be defined manually in a tedious and 
error-prone process. This paper aims to simplify this task by providing a simpler approach and some 
automation. 

1.5 A Solution using Domain Theory 

The approach that we take is to abandon well-founded recursion for this task, and resort to domain theory 
instead, which can express very general recursions over complete partial orders. 

The central trick is that the heap monad can be turned into a pointed complete partial order (pcpo) 
by using the exceptions as a bottom value. Then, any monadic expression built up from pure terms and 
primitive operations, composed with return and bind operation is continuous by construction. This means 
that the standard least fixed-point construction can be used to obtain the function, and that the recursive 
equation can be derived without preconditions. 

A well-developed formalization of domain-theoretic concepts is available with Isabelle/HOLCF [19]. 
While we build on these concepts as a foundation, the constructions are not exposed to the user. 

1.6 Related Work 

The most closely related work is by Bertot and Komendantsky [5], who use fixed-points in flat pcpos 
to define partial recursive functions in Coq [4], augmented with some classical axioms. They also show 
that their extension preserves the possibility to extract programs from Coq developments and provide a 
Coq command that automates the definition process. 
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This work builds on the same foundations, but goes beyond it in two points: 

1 . We manage to provide an induction principle, which enables reasoning about the function without 
having to rely on the underlying iterative construction. This permits induction proofs at a higher 
level of abstraction, which leads to simpler proofs. 

2. By generalizing the approach slightly, we do not only deal with the flat domain of the option type, 
but can also handle other situations such as the heap monad. This elegantly solves the problem of 
making recursive definitions of programs in Imperative HOL. 

Using the monad abstraction to encapsulate partiality is also not new: In the context of constructive 
type theory, Capretta [8] and Megacz [18] describe monads that model non-terminating computations 
coinductively. In a classical logic like Isabelle/HOL, however, the much simpler option monad, which 
simply adds an extra element to express undefinedness, is sufficient. 

The rest of this paper is structured as follows. We first introduce the basic preliminaries from Is- 
abelle/HOLCF (Sect. 2). Then we show how recursive function definitions can be automated in the 
option monad, which is the simplest setting for our approach (Sect.3). Sect. 4 discusses the automated 
generation of induction rules from the general fixed-point induction principle. Then we move back to the 
imperative heap monad (Sect. 5), which is the original motivation for this work. It will be seen that the 
technique generalizes easily to that more interesting case, and we present a more realistic example. We 
compare the method to the domain-predicate-based approach and discuss limitations and other issues in 



Isabelle/HOLCF is a definitional extension of Isabelle/HOL with domain-theoretical concepts from the 
LCF system [11]. Originally developed by Regensburger [22, 21], its design was later improved by 
Miiller et al. [19], notably by the consequent use of type classes. In recent years, the library has been 
maintained and extended by Huffman [14, 15]. 

HOLCF defines a type class of complete partial orders (epos) C, based on which the standard notions 
of chain, (least) upper bounds, and continuity are defined as in Fig. 1. Note that the expression U i. Y i 
only denotes a meaningful value if a least upper bound actually exists. Otherwise its value is arbitrary. 
A cpo is pointed if it has a least element, written _L. Pointed epos are also called pepos. 

One of the basic results of domain theory is a fixed-point theorem, proving that continuous functions 
always have a fixed-point that can be reached by iteration: 



Here, /op F = (|J i. F' _L), and F' denotes iterated function application. 

As one of its main features, HOLCF then introduces a type of continuous functions, written a — > fl. 
While this helps to automate many continuity proofs by turning them into type checking, it also destroys 
the compatibility with regular Isabelle/HOL developments. Since we are trying to simplify function 
definitions in HOL, we do not use the continuous function space. 

More generally, while this work uses concepts from HOLCF, it is important to note that this is 
completely transparent and just part of the internal construction. A user of our tool does not have to 
know domain theory or its formalization in HOLCF. 



Sect. 6. 
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chain : : (nat =4> a) => oooZ 
c/iam y < — >■ (V/. F j C Y {Sue /)) 

ra«ge : : (a /?) => /? set 
range f = {y. 3x.y=fx} 

<| : : a set a oooZ 

5 <| a; ^ — s> (Vy. j G 5 — > yQx) 

<C| :: a set => cr =4> oooZ 

S <C| x <; — 5- S <\ x A (Vm. 5 <| m — t- x C u) 

LI :: or jef =>• a 

(U I'O = (THEx. range Y <| x) 
conZ :: (a =>• jS) => Z?ooZ 

con?/ < — ► (VF. c/iain F — ► range (M.f (Fi)) <|/ (U Fi)) 

Figure 1: Basic definitions of HOLCF 

3 Recursion in the Option Monad 

This section shows how to define partial functions in the option monad. It mainly recalls the standard 
fixed-point construction also used by Bertot and Komendantsky [5], and shows how it is automated in 
Isabelle/HOL. Later we will generalize it to the heap monad. 

We start from the standard option type in Isabelle/HOL, together with the monad operations: 

datatype a option = None \ Some a 

return x = Some x 

None >=/ = None 
Somey^=f=fy 

This monad is known to Haskell programmers as the Maybe monad and models computations with 
failure. However, it can also be regarded as a (flat) pepo, where _L = None. 

This basically (ab)uses None as the result of a non-terminating computation. The fixed-point law can 
thus be used to solve recursive equations fx = F fx, provided that the functional involved is continuous: 

1 . Prove that the functional F is continuous. 

2. Define/ =fixp F. 

3. Conclude the equation/x = F fx using the fixed-point theorem (FlXP). 

Now the primary observation is that if the function is written in monadic style, continuity holds by 
construction and can be proved automatically following the term structure using the rules given in Fig. 2. 

Example 1. As an artificial example, assume some fixed function step :: nat nat and assume that 
we want to define a function trace :: nat => nat list that iterates the step function, until it returns zero, 
keeping all even values in a list. Here is how the function could be written in ML. 
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(/\y. cont (Ax.fxy)) ==> contf (LAM) 

contf ==>- (/\y. cont (g y)) ==> cont (Ax. do y <—fx; g y x done) (Bind) 

cont (Ax. c) (Const) 

cont (Af.fx) (REC) 

contf ==>■ cont g ==> cont (Ax. ifb then fx else g x) (If) 



Figure 2: Continuity rules 



fun trace n = 
if n = then [] 

else if even n then n : : trace (step n) else trace (step n) 

The function is partial and asserting this equation directly in Isabelle/HOL would be unsound. However, 
we can define its monadic counterpart with return type nat list option: (Note that # is Isabelle's way of 
spelling the constructor for non-empty lists) 

trace n = 

(ifn = then return [] 
else do tl trace (step n) ; 

(if even n then return (n # tl) else return tl) 
done) 

The following step-by-step proof shows that continuity of the functional is easily proved in a com- 
pletely syntax-directed way. The proof obligation is as follows. 
1. cont (Atrace n. 

ifn = then return [] 
else do tl <f— trace (step n); 

(if even n then return (n # tl) else return tl) 
done) 

We first move the lambda bound argument out using rule (LAM): 

1. /\n. cont (Atrace. ifn = then return [] 

else do tl trace (step n); 

(if even n then return (n # tl) else return tl) 
done) 

Applying rule (If), we obtain two subgoals: 

1. Arc. cont (Atrace. return []) 

2. /\n. cont (Atrace. do tl <— trace (step n)\ 

(if even n then return (n # tl) else return tl) 
done) 

The first goal is trivial as it contains no recursive call, and can be discharged with rule (CONST). The 
other goal contains a bind, and we decompose it using rule (Bind): 

1. /\n. cont (Atrace. trace (step n)) 

2. /\n tl. cont (Atrace. if even n then return (n # tl) else return tl) 

Now, the first goal is a recursive call, and we apply rule (REC). The other goal is again trivially solved 
using (Const). 
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4 Induction Rules for Partial Correctness 

Defining the function and deriving the recursive equation is always just half of the problem, since one 
wants to use induction to reason about the function. For total functions, the induction principle is a 
consequence of the termination of the function. For partial functions, the function package can generate 
a similar rule, using the domain predicate as a guard. In this section, we show how to derive an induction 
rule for partial functions constructed as least fixed-points. 
HOLCF provides a general fixed-point induction rule: 

odm P =^ cont F^P±=>(/\f.Pf=>P (Ff)) =>- P (fixp F) 

Besides continuity, which is already proved at definition time, the property P must hold for _L and it must 
be admissible, which means that it can be transferred from chains to least upper bounds: 

adm P = (VY. chain Y — ► (Vi. P (Y /)) — ► P (|J i. Y i)) 

While this general rule can be used to reason about the function, it is somewhat abstract and not 
very convenient to use. In particular, the admissibility condition must always be proved when applying 
the rule. Although HOLCF can automate such proofs in some cases, we would prefer to hide these 
inconvenient parts of domain theory completely. 



4.1 Restriction to partial correctness 

It turns out that there is an instance of the general rule which is easier to work with. 

If we restrict ourselves to partial correctness properties, i.e., showing that the result of the function, 
when it is defined, satisfies some predicate, then matters become straightforward. More precisely, we 
replace the predicate P with the instance Af. Mxy.fx = Some y — > Q x y. Then the admissibility 
condition can be discharged once and for all, since this instance is always admissible. 

Thus, iff is the recursive function, and F is the corresponding functional, the following rule can be 
derived. 

f\fx y. (/\z r.fz = Some r ==> Q z r) ==> F fx = Some y =>■ Qxy 
fx = Some y ==> Qxy 

Note that the statement of this rule makes no mentioning of the iterative fixed-point construction. 
Presenting this rule to the user hides the details of this construction, which allows reasoning on a more 
abstract level. 

Example 2. For example, the instance for trace is as follows: 

f\trace n ys. 

(f\z r. trace z = Some r ==> Qzr) =^ 
(if n = then return [] 
else do tl trace (step n); 

(if even n then return (n # tl) else return tl) 
done) = 
Some ys =>• 
Qnys 



trace n = Some ys 



Qnys 
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4.2 Induction Rule Refinement 

The raw induction rule as shown above can still be improved. First, the control flow in the definition gives 
rise to three cases, one for n = 0, one for even n, and one for -i even n. Second, the sequencing using 
»= can be decomposed, since the whole expression is only denned when all relevant subexpressions are 
denned. Moreover, the induction hypothesis is likely to be only useful to prove that the recursive call 
satisfies the property Q. The rule that a user would like to see is roughly the following: 

Q0\\ 

j\n tl. n^ Q (step n) tl ==> even n ==> Qn (n# tl) 
An tl. n ^ Q (step n) tl ==>■ -> even n Q n tl 
trace n = Some ys ==> Qnys 
To arrive at this simpler form, the following steps are necessary: 

1. Decompose the program structure by splitting the function body into smaller steps: 

• A premise (t »= (Ax. fx)) = Some y is replaced by t = Some x and fx = Some y 

• A premise Some t = Some y (which arises from a return statement) is replaced by t = y. 

• Conditionals like (ifb then x else x') = Some y are split up into two cases, with premises b 
and -i b. 

2. Use the induction hypothesis to replace premises of the form f z = Some rbyQzr. When all 
occurrences off are replaced, the general induction hypothesis can be discarded. 

3. Clean up the context by substituting premises of the form v = t where v is a variable. 



5 Recursion in the Heap Monad 

We now move from the option monad to the more interesting heap monad. In fact, not much of the 
process has to be adapted. 

The heap pcpo. Unlike the option pcpo, the heap pcpo is not flat, since its values represent state trans- 
formations. The order is defined as Heap f C Heap g < — > (Vh.fh = bot V fh = g h), where 
bot = (Inr Exn, ho) for some arbitrary but fixed heap 1iq. This implies _L = Heap (Ah. bot). 

Recursive definitions. After proving continuity of »=, which is tedious but straightforward, the defini- 
tion process remains the same as for the option monad. We automatically prove continuity of the 
functional by applying the rules from Fig. 2 in a syntax-directed way. After that, the function can 
be defined as a fixed-point. 

Induction rule generation. In the induction rule, the condition/x = Some y is replaced with its counter- 
part for heap-manipulating programs, the condition (h, h', y) G \ fx ] (cf. Sect. 1.3). The inductive 
property Q now also refers to the heap before and after the computation. As in the option case, we 
must prove that this partial correctness property is always admissible: 

adm (Af. Mx h h'y. (h, h',y) € [fx ] — >Qxhh'y) 

Induction rule refinement. In the refinement process, the program structure is decomposed as de- 
scribed above. For the primitive heap operations, additional refinement steps are added, which 
replace them by their counterparts with explicit heap. For example, the premise (h, h', y) G [ \r ] 
is replaced by y = get-ref r h and h' = h. 
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Example 3. The refined induction rule for traverse has the following form: 
f\h'.Q Empty h'h'\\ 

A/il x rn. Q (get-ref r h\) h\ h.2 n ==> Q {Node x r) h\ ]%2 ft) 

(h,h,y) £ [ traverse x ] ==> Qxhh'y 

Example 4. We now discuss a more realistic example that arises in the formalization of an imperative 
unification algorithm mentioned previously. We refer to Baader and Nipkow [1, ch. 4.8]. for a text- 
book description of imperative unification. To avoid expensive allocations, the algorithm keeps track of 
substitutions by directly updating references in the terms themselves. 

In the formalization, heap-allocated mutable terms consist of variables, constants and binary appli- 
cations: 

datatype a rtrm = Var a (a rtrm ref option) \ Const a \ App (a rtrm ref) (a rtrm ref) 

The type argument a is only used for names. Note that variables carry an optional reference cell, which 
is used to mark that a variable has already been assigned some other term. Applying a substitution for 
that variable only requires an update of the relevant reference, which also affects other occurrences of 
the same variable, since the reference is shared. A value of None means that the variable is unassigned. 

We will only show a simple part of the unification algorithm, namely the function occurs, which 
checks if a variable r\ appears in some term re- 
occurs r\ r2 = 
do t ±- \r2', 
(case t of 
Var n o~ 
ifr\ = r2 then return True 

else case cr of None => return False \ Some r' => occurs r\ r' 
I Const n => return False 
I App 7-3 7-4 do b <— occurs r\ r^ ; 

(ifb then return True else occurs r\ r$) 
done) 

done 

This is a simple recursive traversal of r2, except that in the variable case, the traversal continues if the 
variable has already been instantiated. Since the term on the heap may contain cycles the function can 
diverge. Also note that the check r\ = r2 is a pointer equality test, not structural equality. 

To formulate the correctness property of such a function, it is convenient to re-state the property "n 
occurs in r2" as an inductive relation occurs-in :: heap =^> a rtrm a rtrm bool. Then, the crucial 
property connects occurs and occurs-in: 

(h, h', b) £ [ occurs r\ r2 ] =^ get-ref r\ h = Var c None occurs-in h r\ r2 = b 

Note that there is no assumption that the pointer structures are acyclic, which is implicit in the assumption 
that the call to occurs terminates and returns b. As there is no structural induction principle that can be 
used here, and we must use induction over the computation of the function — in other words, fixed-point 
induction. 

The induction rule produced by our prototype implementation is given below. With this rule, the 
inductive proof of the correctness property is straightforward. Note how the premises of the rule corre- 
spond to the cases in the function definition. 
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An hn cr. Var na = get-ref r\ h ==> P r\ r\hh True 

l\r\ r2 h n. r\ ^ r2 ==>- Var n None = get-ref r2 h ==^ P r\ rjh h False 

y/\ri r2 h'y h n r'. 

r \ 7^ r 2 P r \ r' hh' y ==> Var n {Some r') = get-ref >2 h =^ P r \ rjhh' y 
l\r\ r2 h n. Const n = get-ref r% h ==> P r\ r2 h h False 

An r2 h! h r3 r\ b. App rs ra, = get-ref r% h P r\ r^ hh ' b ==? b =^ P r\ r2 h h' True 
Arj r2 h" y h rj r\ h' b. 
App r-i ya, = get-ref r% h 

P r\ r-i h h b =^> -1 b P r\ r^h h' y P r\ r2h h" y 

(y, n. ^2) £ [ occurs hh'J P hh' y r\ r2 

While this rule looks intimidating at first, our (limited) practical experience suggests that there is no 
way around it. Before automation was available, the definition of the function and the proof of a similar 
induction rule took about 450 lines of very technical proof script, which is more than the correctness 
proof itself. The situation for the rest of the imperative unification algorithm is similar. With our new 
approach, these manual proofs are no longer needed. 



6 Discussion 

Implementation. The implementation of our technique is still in a prototype stage. It works well with 
the examples like the ones presented in this paper but lacks several user-friendly features that would be 
needed for productive use, e.g., support for mutually recursive definitions and pattern matching. More- 
over, the HOLCF dependencies should be reduced to a minimum. 

Higher-order recursion. Currently, our approach expects a fixed set of constructs in monadic terms: 
»=, conditionals, recursive calls, and constant expressions not involving recursive calls (cf. the continuity 
rules in Fig. 2). This basically limits the functions that can be defined to a first-order fragment, since 
recursive calls must be applied and cannot be passed to functional like map or fold. To support higher- 
order recursion, one must handle more constructs, such as a monadic map combinator mapM. Then, a 
suitable continuity rule must be known to the tool, and (optionally) a rule to be used in the induction rule 
refinement step. The format of such rules is not yet entirely clear, and it is part of future work to see if 
this extension is possible and helpful in practice. 

Option type vs. domain predicate. With the ability to define non-terminating recursive functions in 
the option monad, we effectively have a new and alternative technique for defining partial functions. This 
raises the question about the relative merits of the two approaches, and whether one should be preferred 
over the other. While this question can only be answered by comparing the approaches in concrete 
applications, a few general things can be said: 

• The main difference between the techniques is the format of the function itself: while the function 
package produces a total function and a predicate dom that describes the arguments x where fx 
"makes sense", the option method produces a function that returns an option type, where partiality 
is explicit in the result. As a price for this more accurate model, the recursive equation must be 
written monadically, to deal with the bottom values that may arise in recursive calls. 
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• The function package constrains the recursive equations with the domain predicate, whereas the 
option method produces unconditional equations. Thus, partial functions defined using the option 
method can be used with Isabelle's code generator. 

• The function package provides special support for tail-recursive definitions. If the function is tail- 
recursive, the unconditional specification can be derived as a theorem even for partial functions. 

The same functionality could be provided using the domain-theoretic approach: We choose the 
identity monad (i.e., no monad at all), and take the flat pcpo where xC.y = (x = u\/x = y) 
where u is an arbitrary but fixed value. Since the bind operation (which is just application) is not 
continuous, we cannot define arbitrary functions. We can however define tail-recursive functions, 
since they can be written without bind. Thus, tail-recursion can be seen as a special case of the 
monadic approach. 

Other Applications. Up to now, only option and state-exception monads are supported by our ap- 
proach. The question arises whether our treatment can be transferred to recursive definitions in other 
monads, e.g., continuation or resumption monads. This is the subject of future work. 

However, even in the current state, the approach can be of use in scenarios other than Imperative 
HOL: For example, Thiemann and Sternagel [24] use an error monad to formalize a simple XML parser. 
Termination of the parser is irrelevant to the rest of their development, so it is currently assumed as an 
axiom, in order to obtain unconditional equations. Using our approach, these equations should come for 
free, but without axioms. 

Transfinite iteration. There is a variant of the construction, where the notion of chain is generalized to 
arbitrary totally ordered sets instead of just countable ones. Then we can replace the countable iteration 
by a transfinite one, taking the least upper bound for each limit ordinal (this is easy to define inductively). 
Then, the continuity proof obligation for each function can be replaced by the weaker monotonicity. 
Otherwise the definition procedure remains the same, as monotonicity proofs and continuity proofs are 
automated in the same way. The advantage is that it is easier to set up new monads to work with our 
method, since one must only prove monotonicity of bind. On the other hand, it requires that we have 
least upper bounds exist for non-countable chains as well. But in the application of interest this is easily 
satisfied, so it may turn out that this variant of the construction is preferrable. Here, more work is needed 
to fill in the details. 



7 Conclusion 

Monadic functions present a challenge to the automated definition mechanisms based on well-founded 
recursion. We have shown that by using the fixed-point theorem for complete partial orders, such defini- 
tions can be made with surprising ease and result in equations that need no domain condition. Automat- 
ically generated custom induction rules make the resulting functions convenient to use, without having 
to refer to the iterative construction used internally. 

While it is perhaps not surprising that domain theory is up to this task, using it for monadic definitions 
is particularly convenient, since conditions like continuity and admissibility hold by construction, and 
the overhead of handling undefinedness is absorbed by the monad. 
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